1. Field of the Invention
The present invention relates generally to the authorized use of computing resources by computer applications. More particularly, the present invention relates to use of a licensing attribute certificate (LAC) to provide cryptographic binding between a computing resource and attributes related to a computer application, and to provide strong authentication by a trusted computing base controlling the computing resource.
2. Background Information
In a typical untrusted computer environment, a computer application can use available computing resources with little or no authorization or accountability. Examples of such computing resources include a modem or network interface. Another example of such computing resources includes a cryptographic token, which provides cryptographic resources to the computer application.
FIG. 1a depicts a typical computer system 100 made up of several “layers” 101, with two layers 130 and 132 consisting of a number of different modules 102, 103, 104, and 105. Each layer represents a collection of one or more modules at a particular abstraction level in a hierarchy of software code development. Each module represents a collection of computer instructions which perform a particular operation on the data which the module receives, producing some data output from the module. At the top layer 130, module 102 can represent a computer application running on a computer of a user 115. Via a user interface in this example, module 102 receives input 110 from user 115. The input 110 could, for example, represent ordering and payment information in an electronic commerce transaction.
Similarly, module 103 receives data item 112, data item 114, and data item 116 as inputs. The module 103 processes the data items 112, 114, and 116, and produces data outputs 118 and 120. These outputs 118 and 120, in turn, become inputs for computing resource A 106. Computing resource A 106 then processes its data inputs 118, 120, 122, and 124 to produce resource output 126, which is returned to module 102.
In the example system shown in FIG. 1a, layer 130 might be written in a well known high-level language, such as C or C++. Layer 132 can comprise libraries of lower-level functions, that would be usable by other applications in addition to module 102. These libraries could also be written in a high-level language.
In general, layer 134 represents any atomic computing resources that process data. Layer 134 can be cryptographic computing resources, such as those found on a cryptographic token. Layer 134 can also be computing resources that send signals to hardware devices, such as a display or some other peripheral device. Layer 134 can also be computing resources that transform data received from user 115.
A cryptographic token provides the ability to perform cryptographic operations on data. Some examples of cryptographic operations include symmetric encryption (secret key) operations, asymmetric encryption (public key) operations, key exchange operations, hash operations, digital signature operations, and key wrapping operations.
FIG. 1b depicts an example of a system 150 of functional layers that contain computing resources specifically designed for providing cryptographic processing. This system, which does not contain the invention, can be contrasted with the system shown in FIG. 4, which does contain the invention. In the example shown in FIG. 1b, user 152 interacts with a user interface in the computer application 171 of application layer 160. In this example, computer application 171 represents the highest level of abstraction; that is, an interface with user 152. As a result of input 170 from user 152, computer application 171 generates inputs 172 and 174 for a mid-level application programmer interface (API) layer 162. In this example, the mid-level API layer 162 comprises two different mid-level libraries, cryptographic API library A 173 and cryptographic API library B 175. These API libraries 173 and 175 communicate with a low-level API library 177 in low-level API layer 164 via inputs 176 and 178. Finally, the low-level API library 177 communicates with the cryptographic resources via inputs 180 and 182 to software drivers comprising hardware token code stack 179 or software token code stack 181 in driver software level 166. Hardware token code stack 179 interfaces with hardware cryptographic token reader 183. Hardware cryptographic token reader 183 sends data over data path 184 to hardware cryptographic token 187 in order for the data to be cryptographically processed therein. The hardware cryptographic token 187 contains trusted computing base (TCB) 191 which is used to provide computing resources to computer application 171 in the form of cryptographic operations from cryptographic computing resource A 193. Another example of a TCB which can be used to provide cryptographic operations from cryptographic computing resource B 197 to computer application 171 in system 150 is TCB 195 made accessible via software token 189. Software token 189, consisting, for example, of a floppy disk, is accessed via software token code stack 181 and token reader 185, and contains the necessary information to allow computer application 171 to access the cryptographic operations made available via low-level API library 177.
Early cryptographic systems used a secret key approach to secure data. In these systems, each user had the same cryptographic key which was used for both encryption and decryption of the data. As a result, the key needed to be kept secret or else the system could be compromised (thus the name secret key cryptography). In contrast, relatively recent advances in cryptography have led to cryptographic systems which use a mathematically related pair of keys. In these systems, one key is kept private by the user, while the other is made public (thus the name public key cryptography). These key pairs allow for algorithms that provide confidentiality (via encryption); and authentication, integrity, and nonrepudiation (via digital signatures).
The deployment of public key cryptography, especially in a public key infrastructure (PKI), relies heavily on public key certificates. A public key certificate (or just “certificate”) contains the public key of a user, along with information that allows a relying party to evaluate whether or not to trust a user's digital signature produced using the private key corresponding to that public key. In particular, the certificate contains the digital signature of a Certification Authority (CA). In general, the CA is a secure, standards-based, and trusted entity that provides certificate, token, user registration, and directory management services. In particular, the CA issues certificates to subscribers. A CA's signature on a certificate indicates that the CA has verified the identity of the user whose certificate it has signed, and the CA's signature also binds the identity of the user to the public key appearing in the certificate.
The X.509 standard of the International Telecommunication Union (dated June 1997) defines an “attribute certificate” as a “set of attributes of a user together with some other information, rendered unforgeable by the digital signature created using the private key of the certification authority which issued it.” Thus, an attribute certificate contains information to supplement the identity information in a public key certificate.
In addition, the X.509 standard defines “strong authentication” as “[a]uthentication by means of cryptographically derived credentials”. The X.509 standard discusses the property of some public key cryptosystems (PKCSs) in which the enciphering and deciphering steps can be reversed, and goes on to state that this property “allows a piece of information which could only have been originated by X, to be readable by any user (who has possession of [the public key of X]). This can, therefore, be used in the certifying of the source of information, and is the basis for digital signatures. Only PKCS which have this (permutability) property are suitable for use in this authentication framework.” In other words, strong authentication can only be achieved with a PKCS in which the public key reverses the transformation accomplished using the private key, and vice versa.
The Trusted Computer System Evaluation Criteria from the United States Department of Defense (DOD) defines a TCB as “the totality of protection mechanisms within a computer system . . . the combination of which is responsible for enforcing a security policy. It creates a basic protection environment and provides additional user services required for a trusted computer system.” An appropriately designed cryptographic token can, for example, contain a TCB. Appropriate design might include features such as a tamper proof case, nonmodifiable firmware, and zeroization of sensitive data upon intrusion detection. A secure operating system is another example of a TCB.
In the past, systems have been suggested which provide access control over various distributed computer resources. For example, in U.S. Pat. No. 5,339,403 issued to Parker, a system is described which requires a user to present a privilege attribute certificate to a computer application in order to access that application. However, the system according to Parker assigns the privilege attribute certificate to the user, only providing access control over the user to some subset of target computer applications. The system according to Parker does not provide strong authentication as the means for allowing access from a computer application to a computing resource. Furthermore, the system according to Parker utilizes a very complex shared secret (i.e. secret key) approach. The Parker approach relies upon encryption of the privilege attribute certificate using the shared secret key. A secret key system contains inherent key management problems and key compromise problems. In particular, a purely secret key system has no recovery mechanism following a compromise. The only way to recover (i.e. the only way to again provide security after compromise of a secret key) is via a physical redistribution of secret key material.
In addition, prior systems have been developed which provide access control over portable data storage media in a manner which allows tracking the usage of certain data. For example, commonly owned U.S. Pat. No. 5,457,746 issued to Dolphin on Oct. 10, 1995, describes a system which allows a publisher to define and enforce attributes related to encrypted files stored on external media. The attributes in this system could relate to such things as usage of particular data, time-related usage of a resource, or number of log-ons.
For many reasons, it is desirable to control the use of computing resources by a computer application through the use of strong authentication. For example, certain computing resources available on cryptographic tokens, if accessible by the computer application, would render the token unable to be exported from certain countries (such as the United States) unless restricted to use by approved computer applications. If those cryptographic operations could be successfully limited to use by approved computer applications using strong authentication, the cryptographic token could then be exported.
Similarly, it may be desirable to limit the accessibility to cryptographic operations contained in a cryptographic token for licensing reasons, which would require a metering of those operations. For example, a provider of cryptographic products might desire to limit access to operations on a cryptographic token to those entities who have properly licensed those operations from the provider. Alternatively, it may be desirable for developers of software products to control accessibility to their products using strong authentication techniques provided by the use of an LAC, in conjunction with separate computing resources.